View 68HC908_1970965.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

1 inhalt, impressum 2 programmierger?t 68HC908 8 ocr-eingabeger?t 10 einfacher logarithmus 12 compact flash: hardware 17 fletcher prfsumme 18 hashing fr rfids 20 lineare interpolation in tabellen 1 read . me die portierung auf den 68HC908gp32 ist jetzt verfgbar, also wieder mehr zeit fr die zeit- schrift. es ist nicht die beabsichtigte zusammenstellung von artikeln geworden. aber es hat sich inzwi- schen soviel material angesammelt da? es fr eine weitere ausgabe reicht. vorgesehen fr das n?chste heft ist u.a. das filesystem fr die compactflash-karte. die listings sind in nanoforth geschrieben. fr die kon- vertierung in andere forth-varian- ten sollte man im nanoforth-manu- al nachlesen das jetzt in der f08- version verfgbar ist. rafael deliano steinbergstr.37 82110 germering tel 089/8418317 mail@embeddedforth.de v1.0 ( pdf ) : 20. mai 04
rot 2 programmierger?t 68HC908 motorolas flash-controller haben eine weit- gehend einheitliche serielle schnittstelle die programmierung und begrenzt debugging von software erm?glicht. hier ist die anschaltung mittels einplatinencomputer dargestellt. bild 1: grundschaltung um verschiedene controllervarianten unter- sttzen zu k?nnen ist es sinn- voll die schaltung fr das programmierger?t in zwei teile aufzuteilen die zusam- mengesteckt werden. der adapter enth?lt den sockel verdrahtet fr ein bestimmtes derivat. z.b. gp32 ( bild 2 ), qt4 ( bild 3 ) oder kx8 ( bild 4 ). qy4 kann durch parallelschaltung eines 16 pin-sockels in qt4- adapter integriert werden. die grundschaltung ( bild 1 ) ist universell und belegt drei ports an einem mitsubishi 6502 einplatinen- computer. schaltung um stecken und entnehmen des con- trollers zu erleich- tern sind alle pins per software abschaltbar. fr pro- grammiermodus ist typisch erh?hte spannung am /irq-pin n?tig. diese spannung betr?gt 7,5 ... 9v bei einer stromaufnahme von 140ua die moto- rola allerdings nicht spezifiziert. in anderen betriebszust?nden sind auch 0v oder 5v an diesem pin erforderlich, soda? er auf alle 3 pegel einstellbar ausgefhrt ist. fr die 0v ist ein ca3240 mit seiner cmos-eingangs- gnstiger als ein lm358. die versorgungsspannung 5v sollte speziell beim gp32 mit maskenfehler ( code 3j20x ) einen niederohmigen entladewiderstand haben, hier 4,7k + 1,0k. damit wird der 100nf kerko im adapter schnell auf unter 100mv entladen was fr die funktion des power-on resets in diesen controllern wnschenswert ist. die monitorschnittstelle be- steht hier nur aus einem portpin mit pullup-widerstand. das datenformat entspricht einer uart. aber da das protokoll halbduplex ist, kann diese leicht in software nachgebildet werden. der resetpin kann wahlweise manuell ber taster geschaltet wer- den, wofr der kerko als entprellung n?tig ist. der kleine kerko auf dem gp32-adapter verhindert berspre- chen vom 9,8mhz takt und ist nur bei ungnstiger leiterbahnfhrung erforderlich. alternativ kann man resetpuls per software ausl?sen, wobei nach hochschalten eine verz?gerng im programm n?tig ist, um die zeitkonstante des kerkos auszugleichen. w?hrend des programmier- betriebs wird die cpu durch einen externen takt versorgt. die beiden blichsten frequenzen werden deshalb im grundger?t erzeugt. typisch wird 9,8mhz ben?tigt. einige controller haben intern als rc-generatoren statt externe quarze. diese sind per flash ab- gleichbar. den abgleich kann das programmierger?t machen. zur aus- gabe des takts fr messung ist es ntzlich vom adapter an einen pin des mitsubishi eine leitung zu fhren, die hier als clk bezeichnet ist.
3 bild 3: adapter qt1 bzw. qt4 bild 4: adapter kx8 bild 2: adapter gp32 gr??ere varianten des 68HC908 wie der gp32 haben eine uart eingebaut. eine weitere serielle schnittstelle zum controller ist fr ein programmierger?t nicht notwen- dig. aber z.b. fr tests von software doch oft ntzlich. hier wurde deshalb eine 65c51-uart an die ports ge- h?ngt. dieser typ ist inzwischen ob- solet, ein 16c550 wrde die gleiche funktion erfllen. da der gp32 ein 32k byte flash hat wurde es auch n?tig den speicherbereich des mitsubishi durch ein gebanktes 128k sram zu erwei- tern. die portpins fr die steuerung der banks werden von der 65c51 uart mitverwendet. erweiterungen die in bild 1 dargestellte schnittstelle ist ein kompromi? aus flexibilit?t und aufwand. einige features fehlen noch. fr controller mit internem rc-generator w?re es gnstig, auch die versorgungsspannung des con- trollers per d/a-wandler des mitsubishi von 2,7v - 5,5v einstell- bar zu machen. denn dieser takt ?ndert sich etwas mit der spannung. man k?nnte damit noch genauer abgleichen. erste voraussetzung dafr ist eine umstellung der 1 pin monitor- schnittstelle auf 2 pins rxd und txd, soda? man die pegelumsetzung leichter durchfhren kann. die mssen dann natrlich auch an allen anderen schnittstellenpins eingebaut werden. speziell bei controllern in smd-bauform ist es angebracht diese erst einzul?ten und dann zu program- mieren. kontaktierung erfolgt dabei typisch ber nadeladapter. dabei sind weitere guardschaltungen n?tig, damit die beschaltung im zielsystem geeignet neutralisiert wird. auch wenn die beschaltung dafr im adapter vorgenommen wird, sind meist erhebliche anpassungen in der grundschaltung n?tig. monitor die beschreibung der schnitt- stelle findet sich in den motorola- unterlagen. hier ist deshalb nur dargestellt wie sie in der software abgebildet wurde. die schnittstelle ist zwar halb- duplex auf einem pin, entspricht aber sonst nominell dem format einer uart mit 9600 baud 8n1, bei einer busfrequenz des controllers von 2,45 mhz. der 68HC908 macht sie in software, weshalb diverse pausen eintreten, in denen er die schnittstelle nicht bedient. es hat sich deshalb herausgestellt, da? es auch im host sinnvoll ist die schnittstelle per software zu emulieren. echte uart macht nur probleme. die unterste ebene der uart- funktionen: (emit) \ in: akku (key) \ out: akku break? \ ( f1 ) 1 = error break! \ ( ) neben dem lesen und schreiben von bytes wird auch erzeugen und erken- nen von break-signalen, also 11 bits low, ben?tigt ( listing uart0 ). im protokoll kommt jedes byte das der host schickt vom controller als echo zurck. c!^? \ ( c f ) f=1 error c!^ \ ( c ) !^ \ ( n ) c@^ \ ( c ) @^ \ ( n ) die n?chste befehlsschicht fhrt das lesen und schreiben von bytes und 16 bit worten ( fr adressen ) zusam- men mit den n?tigen verz?gerungen durch. die oberste schicht bildet den befehlsumfang den das monitor-rom des controllers hat direkt ab ( listing uart1 ). sobald die monitorver- bindung aufgebaut ist, kann man diese befehle interaktiv von forth aus benutzen. grundlegend sind tc@ ( motorola: ?read ) byte lesen und tc! ( ?write ) byte schreiben im 64k adre?raum. erg?nzend dazu gibt es ?indexed varianten itc@ ( ?iread ) und itc! ( ?iwrite ) bei denen die adresse automatisch inkrementiert wird und deshalb nicht bertragen werden mu?. itc@ hat die eigenheit beide folgenden bytes auszulesen. tc@ \ ( adr c1 ) tc! \ ( c1 adr ) itc@ \ ( c1 c2 ) itc! \ ( c1 ) readsp \ ( addr ) run \ ( ) um sich den speicher als hexdump auf den bildschirm zu holen ist ntzlich: tdump \ ( addr )
4 programmausfhrung run ( ?run ) wird ber rcksprung aus irq-unterprogramm realisiert. beim einstieg in monitormodus wurde von der cpu ein psh, und swi, opcode ausgefhrt. ersterer legt das obere byte des 16 bit x-registers auf den stack. swi ist ein per opcode aus- gel?ster interrupt. wo stackpointer gerade hin- zeigt kann man durch den befehl readsp ( ?readsp) auslesen. man kann den stack also passend mit tc! doktern bevor man mit run den rcksprung auf neue adresse aus- fhrt. soweit testprogramme die man ins ram des controllers geladen hat mit dem rti, -opcode enden, kehren sie in den monitormodus zurck. es ist aber dann noch ein break n?tig um die schnittstelle wieder zu aktivieren. monitor entry mit dem befehl up schaltet man am programmieradapter die versorgung des controller ein. mit dem befehl down schaltet man sie aus. hat man die versorgung hoch- geschaltet, mu? der host erst 8 bytes sicherheitscode schicken, die mit flash verglichen werden. bei fabrikneuem controller ist der inhalt normalerweise ff. aber die bytes des sicherheitscodes sind auch die interruptvektoren, also nach pro- grammierung einer applikation meist zwangsl?ufig ver?ndert. die 8 ref- erenzbytes werden deshalb aus der variable sec-code entnommen die auf ff initialisiert wurde. ver?ndert man die bytes im controller mu? man die bytes in der variable anpassen. bei eingabe eines falschen codes geht der controller in einen eingeschr?nkten monitormodus. von dort kann man das flash zumindest komplett l?schen. ob die initialisie- rung korrekt war, kann man durch lesen eines bytes im ram feststel- len. der befehl up tut das und druckt eine warnung wenn man initialisie- rung nicht voll geschafft hat ( listing prog 2 ). programmierung die blichen funktionen, die der benutzer haben will, kann man direkt auf forth-befehle abbilden ( tabelle 1 ). verify und erased? kann man auf read zurckfhren, wenn diese funktion einen eigenen zwi- schenspeicher im ram hat. man liest dann erst mit read komplett aus und fhrt verify und erased? bequem gegen daten im ram durch. dadurch umgeht man insbesondere probleme die sich aus der fragmentierung des speichers ergeben. das flash ist nominell in einzelne pages organisiert. diese sind bei gro?en controllern 64d, bei klein- en 32d bytes lang. man kann das flash entweder komplett l?schen ( ?bulk-erase ), oder nur eine einzel- ne page. letzteres wird hier nicht benutzt. schreiben von flash ist byteweise m?glich. aber nicht so einfach wie z.b. bei eeprom, son- dern mit routinen die auf pages ausgerichtet sind. fr gro?e controller wie den gp32 mssen alle flash-grund- funktionen durch programme die man ins ram des controllers kopiert und dort ausfhrt realisiert werden. kleine varianten wie der qt4 haben nicht gengend ram, motorola hat des- halb zus?tzlich ein rom mit unter- programmen eingebaut. die program- me im ram werden dadurch gen- gend klein. man hat aber nun die programmstruktur etwas starr vorge- geben. um die software fr das programmierger?t einheitlich zu halten, wurde deshalb anhand des qt4 implementiert und dann auf gp32 portiert. tabelle 1: anwenderbefehle program \ ( f ) f = 1 error copy ram to flash erase \ ( f ) f = 1 error erase flash read \ ( f ) f = 1 error copy flash to ram verify \ ( f ) f = 1 error compare to flash erased? \ ( f ) f = 1 error check if flash = ff rom-routinen fr qt4 & kx8 die unterprogramme des zu- s?tzlichen roms sind zwar iden- tisch ausgefhrt, die adressen fr speicherbereiche, variablen und einsprungpunkte variieren aber ( tabelle 2 ). daten belegen dabei im ram den bereich ab data mit bis zu 32d byte l?nge, d.h. einer page des flash. der endwert wird in der variable laddr vorgegeben, w?hrend der startwert faddr bei aufruf der entsprechenden routi- nen in akku und x-register berge- ben wird. beide werte mssen nicht auf page-grenzen abgestimmt sein. getbyte dieses unterprogramm liest ein byte ber die monitorschnitt- stelle ein. auf echo des bytes wird hier aber verzichted um die ge- schwindigkeit der datenbertra- gung zu erh?hen. beispiel: ddra 0 mbc, \ inputpa0 getbyte jsr, rdvrrng dieses programm dient zum lesen bzw verifizieren von flash. wenn beim aufruf der akku null ist werden die daten auf der monitor-schnittstelle ausgegeben. wenn bei aufruf der akku ungleich null ist, werden die daten in data abgespeichert, nachdem sie vorher mit den dort liegenden daten ver- glichen wurden. ergebnis des ver- gleichs enth?lt das carry flag. ist es gesetzt ist, war der vergleich ok. ferner enth?lt der akku die prf-
summe ber die gelesenen daten. beispiel um von f000 bis f010 auf monitorschnittstelle auszugeben: a. clr, f010 #. ldhx, laddr sthx, f000 #. ldhx, rdvrrng jsr, erarnge l?scht flash pageweise bzw. den kompletten speicher. wenn bit 6 in variable ctrlbyt gesetzt ist wird der kom- plette speicher gel?scht. andernfalls nur eine page ( 32 byte ). die page wird durch startwert spezifiziert und ist an pagegrenzen ausgerichtet. da frs timing die verz?gerungsschleife delnus verwendet wird, mu? fr diese die variable cpuspd initiali- siert sein. diese routine war in den ersten versionen des qt4- bzw., kx8- controller teilweise defekt. es wird dann irrtmlich der die page der vektoren gel?scht. um den komplet- ten speicher zu l?schen jedoch auch dort verwendbar. beispiel um mit 8 mhz ( 8x4=20h ) taktfrequenz kompletten speicher zu l?schen: cpuspd 20 #. mov, ctrlbyt 6 mbs, f000 #. ldhx, \ dummy erarnge jsr, prgrnge bytes von data in flash schreiben. dabei wird angenommen, da? das flash bereits gel?scht ist. es wird auch kein verify durchgefhrt. da frs timing die verz?gerungsschleife delnus verwendet wird, mu? fr diese cpuspd initialisiert sein. delnus die verz?gerungsschleife wird durch die bergabe von werten in akku und x-register programmiert. dabei spezifiziert der akku die busfrequenz der cpu ( tabelle 3 ) von z.b. 1 mhz. bei diesem wert w?re der verz?ger- ungswert in x von 1 - 255 * 12usec einstellbar. wenn der takt anders als 1 mhz ist, mu? man die 12usec auch passend skalieren. erarnge und prgrnge liefern den wert fr akku selbst, aber die bus- freqenz mu? man in der variablen cpuspd vorher initialisieren. fr die busfrequenz 2,45 mhz also mit 0ah. fr 8 mhz mit 20h. tabelle 2: adressen qt4 kx8 ram start 80 40 ctrlbyt 88 48 cpuspd 89 49 laddr 8a 4a 1+ 8b 4b data 8c 4c max ab 6b i/o monitor-pin pa0 pa0 stack flash-rom used: getbyte 2800 1000 4 byte rdvrrng 2803 1003 6 erarnge 2806 1006 5 prgrnge 2809 1009 7 delnus 280c 100c 3 tabelle 3: taktanpassung akku = operating frequency 0 illegal 1 0,25 mhz 2 0,50 mhz 3 0,75 mhz 4 1,00 mhz usw. flasher fr qt4 da fr jede controller-variante eine menge adressen neu zu definie- ren ist, werden diese beim compilieren per file festgelegt ( listing prog2 ). dort wrde man auch anpassung an variante qt1 mit kleinerem speicher machen. um datenbl?cke und program- me ins ram des controller zu ber- tragen und dann auszufhren, gibt es einheitliche unterprogramme: tcopy \ ( c1 ) \ c1 = number of bytes dcopy \ ( ) \page of data 32 bytes texecute \ ( ) da das l?ngste programm nur 70 bytes lang ist, pa?t es bequem in die zeropage. im host liegt der 8k haupt- speicher buffer von 6000 ... 7fff. hier wird das programm fr den controller per cross-compiler oder intel-hex-loader abgelegt. (read) hat seinen zwischenspeicher (buffer) von 4000 ... 5fff flash-programmierung das flash ist leider v?llig fragmentiert. es gibt einzelne bytes die man programmieren mu?. kleine bl?cke wie die vektoren. und den umfangreichen hauptspeicher. aus diesem grund sind zwei treiber n?tig: (32prog) und (stream-prog) . beide fhren auch verify durch und geben entsprechen- des flag zurck. (32prog) erledigt einzelne bytes und 32 byte pages oder abschnitte bild 5: memorymap host 32ksram fr targets bis 8k byte 5
innerhalb einer page. datenbertra- gung erfolgt langsam mit dcopy ( listing prog4 ) (stream-prog) akzeptiert fr anfang und ende nur auf 256 byte bl?cke ausgerichtet grenzen. erledigt den hauptspeicher aber in einem durchlauf. dazu empf?ngt das geladene programme ber die monitorschnittstelle pages zu 32 bytes und programmiert sie. dann gibt es kurz einen kurzen lowpuls auf der schnittstelle aus, um die n?chste page anzufordern ( listing prog5 ). mit diesen beiden grund- befehlen verarbeitet der befehl program alle teilbereiche ( listing prog6 ). das schreibschutzregister flbpr kann danach durch den befehl prog-flbpr geschrieben werden. wenn der speicher des controllers nicht komplett durch ein programm belegt ist, kann man die programmierzeit fr den haupt- speicher verkrzen, indem man nur bis zur programmobergrenze pro- grammiert. dazu mu? der buffer vor dem compilieren auf ff initialisiert sein, damit man die grenze feststellen kann. erase im qt4 denkbar harmlos, weil man nur die routine im rom aufru- fen mu? ( listing prog7 ) 6 flasher fr gp32 dieser controller hat viel ram und deshalb kein zus?tzliches rom. die programme die man deshalb ins ram l?dt werden entsprechend l?nger, hier bis zu 200 bytes. in der zeropage kommen deshalb nur die daten unter. programme werden ab 0100h gespeichert. die flash-page dieses controllers ist 64 bytes. ansonsten ist die software ?hnlich wie fr den qt4 aufgebaut. erase hat die besonderheit, da? man eine adresse in der soft- ware ?ndern mu?, wenn mit falschem security string initialisiert wurde. das wird aber ber ein flag das von up gesetzt wird automatisch gesteu- ert. da dieser controller 32k byte flash hat, sind die speicherpro- bleme im host gravierend, wenn man eine 8 bit cpu verwendet. hier wurde das 32k sram deshalb durch ein gebanktes 128k sram ersetzt ( bild 6 ). der hauptspeicher buffer in bank = 0 ist trotzdem auf 16k byte begrenzt. die verdeckten speicher- seiten bank 1, 2, 3 sind umst?ndlich anzusprechen und werden deshalb nur von (read) verwendet ( tabelle 4 ). erased? kann unschwer den gesamten speocher prfen. program und verify sind jedoch auf 16k byte beschr?nkt. dieses wird durch die variable map eingestellt ( tabelle 5 ). die (un)freiwillige beschr?n- kung auf 16k byte hat ihre ursache in der geschwindigkeit: um 16k mit 9600 baud zu bertragen, braucht man bereits 17sec. programmierzeit im controller und allgemeiner overhead dehnen das nochmal deutlich. man mu? sich fr controller mit grossem speicher also von der kompatibilit?t zum qt4 beim inter- nen aufbaus der software l?sen und vor allem die datenbertragung beschleunigen. wenn man den controller auf programmierger?t in bild 6: memorymap host 128k sram fr targets gr??er 8kbyte read auch hier erm?glicht es (read) eine routine im rom vom start des hauptspeicher bis ffff in einem zug die bytes herauszulesen und im zwischenspeicher abzulegen. erased? vergleicht den inhalt des zwischenspeichers mit ff, w?hrend verify den vergleich gegen den hauptspeicher durchfhrt. read kopiert hingegen den zwischenspei- cher in den hauptspeicher. tabelle 4: bank-zuordung fr (read) host target ( bank=1 4000 ... 7fff 4000 ... 7fff ) bank=2 4000 ... 7fff 8000 ... cfff bank=3 4000 ... 7fff d000 ... ffff tabelle 5: map-zuordnung fr program, verify host bank=0 target map=0 illegal map=1 4000 ... 7fff 4000 ... 7fff map=2 4000 ... 7fff 8000 ... cfff map=3 4000 ... 7fff d000 ... ffff sockel steckt, kann man die bytes z.b. auch parallel ber portpins einlesen. auch schnellere serielle verfahren fr in-circuit programmie- rung auf der leiterplatte sind denk- bar.
7 frequenzkalibrierung qt4 & kx8 der 12,8 mhz rc-oszillator der q-typen hat unabgeglichen nur eine genauigkeit von +/-25%. moto- rola liefert zwar in einem flash- register einen korrekturwert der ihn auf +/-5% bringt. l?scht man das flash jedoch via bulk-erase, geht auch der korrekturwert verloren. die eigentliche steuerung des oszillators erfolgt dabei durch das i/o-register 0038 osctrim das durch reset auf 80h eingestellt wird. der flash-korrekturwert liegt in ffc0 trimloc und enth?lt nach mass-erase ff. fr die initialisierung nach reset ist der anwender zust?ndig. z.b. nach reset so: ffc0 lda, 0038 sta, signal im monitor-betrieb mit hoher spannung am /irq-pin wird der controller durch den externen takt gespeist. schaltet man die spannung am /irq-pin auf 5v, wird auf internen oszillator umgeschaltet. gleichzeitig wird auch der watchdog aktiviert. dieser l?st nach 81,9msec aus. man l?dt also erst in den controller ein programm das eine 100hz frequenz am monitorpin erzeugt und gleichzeitig den watch- dog bedient. wenn dieses l?uft senkt man die spannung an /irq ab. damit wird die busfrequenz von quarzgenau 2,45 mhz auf nun nominell 3,2 mhz umgeschaltet und das rechtecksignal ?ndert sich entsprechend. timer auf dem mitsubishi-ein- platinencomputer ist es am einfach- sten den 10msec lowpuls in einer z?hlschleife in software auszulesen. dieser 16 bit timer hat eine aufl?- sung von 8,98usec. die genauen werte der schleifen in beiden cpus sind nicht so kritisch, da man ja mit den 2,45 mhz einen kalibrierlauf machen kann um den sollwert zu bestimmen. tabelle 6 zeigt me?wewerte von einem controller. wie man dort auch sieht deckt der korrekturbereich von osctrim typisch +/-25% ab ( tabelle 7 ) und kann als n?herungsweise linear angenommen werden. nach einer messung mit osctrim = 80h ist es deshalb m?glich anhand des messwerts und des sollwerts tsoll ( hier 1111 ) einen neuen korrekturwert fr osctrim ausrechnen der schon ziemlich genau ist ( bild 7 ). bei der berechnung mu? man allerdings zus?tzlich schranken setzen ( t-limit-, t-limit+ tabelle 8 ), damit man den ergebnisbereich 00 ... ff bei ungnstigen eingangswerten nicht berschreitet. da man aber nicht sicherstellen kann, da? die gewnschte toleranz unmittelbar getroffen wird, ist die verwendete kalibrierroutine ( listing calib ) zweistufig. nach dem grob- schritt mit der formel wird in bis zu 10 schritten noch um +1 bzw. -1 ge?ndert um das toleranzband zu erreichen. da jeder schritt etwa 0,2% entspricht, sollte eine frequenz +/-0,5% leicht erreichbar sein ( tabelle 8 ). den endgltig bestim- mten wert wird man im haupt- speicher bei trimloc able- gen und dann alles zusammen mit program ins flash tabelle 6: me?werte eines musters 1451 * 8,98usec = 13,03msec @ 2,45 mhz quarz ( 1111 9,97 soll 3,2 mhz ) 1368 12,28 @ osctrim = 80h 1081 9,71 00h 1638 14,71 ffh tabelle 7: nomineller einstell- bereich osctrim 00h = -25% = 0,75 80h = 0% = 1,00 ffh = +25% = 1,25 bild 7: formel zu berechnung des korrekturwerts (512+128) - ( t80h * 512 / tsoll ) = osctrim kx8 die frequenz wird durch eine pll aus einem internen 307,2khz rc-oszillator erzeugt. dieser schwankt durch bauteilstreuung um +/-25%, kann aber durch durch laden eines korrekturwerts in 0038 icgtr abgeglichen werden. nach reset ist 80h geladen. der takt ist in schritten von 0,2% abstimmbar. der prozessor h?tte im rom trimroutinen [3], die hier aber nicht verwendet werden. die software fr den qt4 ist n?mlich direkt verwend- bar. auch hier wird nach absenken von /irq von 9v auf 5v vom exter- nen takt auf den internen umgeschal- tet. da der frequenzmultiplizierer bei reset auf 21d initialisiert wird, ergibt sich ein 6,45 mhz takt. daraus die busfrequenz 1,613 mhz. die ge?n- derten konstanten zeigt tabelle 9 [1] motorola an1831 ?using c68HC908 on-chip flash programming routines [2] an2312 ?mc68HC908qy4 internal oszillator usage notes [3] an1831 ?using mc68HC908 on-chip flash programming routines tabelle 9: kx8 1,613 mhz d% 1658 constant t-limit- d% 2192 constant t-soll-% \ +0,5% d% 2204 constant t-soll d% 2215 constant t-soll+% \ -0,5% d% 2759 constant t-limit+ tabelle 8: konstanten qt4 3,2 mhz d% 836 constant t-limit- d% 1105 constant t-soll-% \ +0,5% d% 1111 constant t-soll d% 1117 constant t-soll+% \ -0,5% d% 1389 constant t-limit+ kopieren. alternativ kann man mit (32prog) auch eine routine schrei- ben die nur das einzelne byte pro- grammiert.
focus 8 im kopf ( bild 2 ) sind steckbar zwei glhlampen angebracht die mit regelbarer lichtst?rke das papier be- leuchten. hinter einer etwa 4cm langen optik befindet sich ein ccd- bildaufnehmer mit 16x64 pixel auf- l?sung. aus der optik wird ber eine bpw34 fotodiode die lichtst?rke ausgekoppelt und ins steuerger?t bertragen. das grne led dient als rckmeldung fr den benutzer, seine steuerleitung wird aber auch in der schaltung verwendet. verbindung zum hauptger?t erfolgt ber einen 15pol subd- stecker auf dem alle signale logik- pegel haben ( tabelle 1 ). die strom- aufnahme der 5v variiert stark mit der beleuchtung durch die glh- lampen. das signal an pin 6 zeigt ber das in die ccd reflektierte licht an ob die pistole papier im blickfeld hat. die eigent- lichen daten kommen mit ttl-logikpegel an pin 7 und der rahmentakt an pin 12. takt wird vom steuerger?t an pin 11 dazu geliefert. ocr-eingabeger?t eigenbau ist wegen der ben?tigten mechanik und optik mhsam. alternative ist die ?pistole ( bild 1 ) eines optoline 3130 bzw 3140 der cgk konstanz. die ger?te wurden ab ca. 1983 herge- stellt und sind heute oft ausgemustert preiswert erh?ltlich. bild 2: blockschaltbild bild 1: leseger?t schaltung hier nur in den wichtigsten teilen schematisch dargestellt. der ccd-bildaufnehmer ( bild 3a ) wird mit 1/16 der zugefhrten 3,3mhz gespeist und liest die 16 zeilenpixel parallel aus. diese analogsignale werden ber lm339 kops auf 1 bit digitalisiert ( bild 3b). die regelschleife zur steuerung der schaltschwelle der kops und der lichtst?rke ist analog aufgebaut. der mittelwert aus allen 16 pixel dazu l??t sich mit widerstandsarrays leicht bild 3b: komparatoren & schieberegister bild3a: ccd
led thres 10 led grn 120 9 bestimmen ( bild 3c) . das digitale 16 bit datenwort wird mit den beiden 74ls166 schieberegistern auf seriell gewandelt und aufs kabel ausgege- ben ( bild 3b). der rahmentakt frame wird in der ccd erzeugt und pulst w?hrend der obersten zeile high ( bild 4 ). adapter als steuerger?t wird hier ein 8 bit einplatinencomputer basierend auf mitsubishi-6502 mit 32kbyte ram verwendet. der kann natrlich nicht den kontinuierlichen daten- strom aufnehmen, aber einzelne bilder. die seriellen daten vom kabel werden ber schieberegister wieder in in ein 16 bit datenwort gewandelt ( bild 5 ). mit dem orginaltakt 3,3 mhz kommen die datenworte ca. alle 5usec. das ist ann?hernd durch linearen code [1] zu bew?ltigen. dazu mu? aber das leseger?t mit dem takt des prozessors gespeist werden. durch die laufzeit der opcodes hat man starres teilerverh?ltnis. hier ergibt sich z.b. da? die adressen der schieberegister in der zeropage als auf ports liegen mssen, damit jeder zugriff 16 zyklen dauert. das ist ein ?gerader wert der mit der synchron laufenden externen logik nachgebil- det werden kann. da aber keine zwei ports komplett frei sind, mssen hier die beiden pins der uart ber einen 74hc4053 w?hrend des einlesens eines bildes abgetrennt werden. tabelle 1: schnittstelle am orginalen steuerger?t 1 gnd 2 gnd 3 5v 320ma max. 4 5v 5 -12v 150ma 6 out focus ( sn75140 ) 1 = out of focus 0 = in focus 7 out data ( 74ls166 ) 8 nc vom grundger?t low gesendet 9 nc vom grundger?t mit 10k auf 5v gezogen 10 in led ber 120 ohm an 5v 0 = led on ( 20ma ) 1 = led off im grundger?t 350usec takt mit etwas ber 50% taktverh?ltnis 11 in clk ( 75140 ) 3,3 mhz 12 out frame ( 75140 ) rahmensignal: ca. 320usec low dann ca. 5usec high 13 nc 14 out light open collector mit 1,5k pullup lowpegel: -0,8v 15 nc mit den 9,84 mhz des controllers ergeben sich an der schnittstelle so 2,45 mhz, also 25% weniger als im orginal. verdaut das leseger?t aber recht gut. man k?nnte den quarz des controllers auf 12,28 mhz erh?hen, kommt dann auf 3,07 mhz also -7%. allerdings mu? man dann die einstellung der baudrate in der uart in der forth-firmware patchen. da das kabel 2m lang ist, sind an data, frame, clk passende terminierungen n?tig. trotzdem sind die pegel nicht optimal weil 74hc und ttl-logik gemischt sind. die schaltschwelle der kops wird durch das signal led vom grundger?t mitbeeinflu?t. es hat am orginalger?t die periode eines frames und 50% tastverh?ltnis. dabei wird der lowpuls konstanter l?nge in der mitte innerhalb des frames hin- und hergeschoben. die nachbildung hier ist stark vereinfacht, es erfolgt manuell eine feste einstellung durch poti. das hat sich bei vorlagen mit gutem kontrast als ausreichend erwiesen. bild 3c: schaltschwellenregelung bild 4: timing schnittstelle und adapter- schaltung bild 6 : ausdruck als ascii
/led 5v 5v /frame 470k 1nf 1nf 250k 22k 10 der orginale synchronisier- ungspuls frame ist zu kurz, als da? man ihn in software an einem port detektieren k?nnte. er wurde deshalb in der schaltung per monoflop als l/frame auf 10usec verbreitet. software die leseroutine ( listing cgk.f74 ) wartet auf den frame- puls in einer schleife: 1 $: 1 $ p6 4 bbs, \ 5cyc der sich ergebende jitter von 0 - 5 cyc ist tolerierbar. das lesen eines 16 pixel-worts sieht dann so aus: p3 lda, hhhh sta, \ 8cyc p5 lda, hhhh 1+ sta, \ 8cyc nach 64d solcher sequenzen ist ein bild eingelesen. das teilprogramm ist damit etwa 700d byte lang. man beachte, da? bei den pixel 0 = schwarz entspricht und einige zeilen umgeordnet werden mssen. fr provisorische ausgabe als ascii- grafik aufs terminal empfielt sich dieses auf vt52-emulation einzustel- len, damit man einen home-befehl hat, der den cursor nach rechts oben zurcksetzt. da das format eines terminals 80 zeichen x 25 zeilen ist, ist es sinnvoll das 64x16 pixel bild liegend auszugeben. bild 6 zeigt eine ausdrucke, hier wieder stehend. die buchstaben mssen feste gr?sse haben, etwa 3 x 1,5mm um voll ins sichtfeld zu passen. es hat sich au?erdem ergeben, das zwar buchstaben aus bchern oder mit bleistift geschriebene zeichen guten kontrast ergeben. nicht jedoch schwarze tinte oder ausdrucke von tintenstrahldrucker. vermutlich vertr?gt die ccd den unterschiedli- chen ir-anteil nicht. [1] emb 1 s. 15 bild 5: schaltung adapter /led
11 scanbit die simpelste n?herung ist sich bei einer positiven zahl das h?chste gesetzte bit zu suchen ( bild 1 ). die funktion gibt es bei manchen 32 bit risc-prozessoren im befehlssatz, weil fr normalisierung von floats ntzlich. dafr wird manchmal der name ?scanbit verwendet. im arm hei?t er clz, ?count leading zeros. entsprechend gibt es auch den befehl ?spanbit der die h?chste ge- setzte null findet. fr negative 2er- komplementzahlen. allerdings ist in software wohl eine bitweise invertier- ung des datenworts gefolgt von scanbit angemessener. die werte von scanbit entspre- chen der funktion y=lb(x)+1. wobei lb der bin?re logarithmus ist. da taschenrechner den manchmal nicht haben, ist die umrechnungsformel ber ln fr nachrechnen von hand ntzlich ( bild 2 ). etwas problematisch ist der hohe datenverlust, wenn man 16 bit auf 4 bit staucht. ( listing scnbit.f74 ) bitlog man kann das verfahren natrlich verfeinern indem man mehr bits auswertet. unter dem namen bitlog ist eine solche variante in [1] fr 16 bit integer angegeben ( bild 3 ). dabei werden die 3 folgenden bits hinter dem fhrenden bit zur verede- lung verwendet. die berechnung entspricht relativ gut y=8(lb(x)-1). bei eingangswerten 0 ... 7 treten allerdings probleme auf soda? ein patch n?tig ist ( tabelle 2 ) . man beachte auch den unterschied der kennlinie zu echtem logarithmus in diesem bereich ( bild 4 ): letzterer l?uft auf 1. die 16 bit werden auf etwa 7 bit gestaucht, der maximalwert fr y ist 119d. das verfahren l??t sich unschwer auf 32 und 64 bit daten- worte skalieren ( tabelle 3 ). in tabelle 4 sind speicher und laufzeit fr assemblerroutinen auf mitsubishi- 6502 mit 2,54 mhz busfrequenz angegeben ( listings bl16.f74 , bl32.f74 bl64.f74 ) einfacher logarithmus speziell fr dynamikkompressoren sind oft nur sehr grobe n?he- rungen n?tig. da die datenworte dabei sehr breit sind, empfehlen sich tabellen wegen des speicherverbrauchs nicht. tabelle 1: y = scanbit(x) x y ( 0 0 ) 1 0 2 1 4 2 8 3 16 4 32 5 ... 16384 15 tabelle 2: y = bl16(x) x x bin?r b n y 8 ...1000 3 0 16 7 ...0111 14 6 ...0110 12 5 ...0101 10 4 ...0100 8 3 ...0011 6 2 ...0010 4 1 ...0001 2 0 ...0000 0 tabelle 3: skalierung von bitlog von 16 auf 32 und 64 bit y= 8(b-1)+n b = 0 ...15d n = 3 bit x<8 y= x*2 ymax = 119d y=16(b-2)+n b = 0 ...31d n = 4 bit x<16d y= x*2 ymax = 479d y=32(b-3)+n b = 0 ...63d n = 5 bit x<32d y= x*2 ymax = 1951d tabelle 4: bitlog speicher & laufzeit byte usec bl16 60 25 - 100 bl32 90 50 - 150 bl64 120 50 - 250 bild 2: umrechnung ln auf lb bild1: scanbit bild 3: bitlog 16 15 8 0 0 00 0000 1 xxxxx 00 1 } b=8d y = 8 ( b - 1 ) + n n=2d 15 8 0 0 00 0000 1x x xxxxxx expander aus beiden verfahren lassen sich auch umkehrfunktionen bilden die sich dann ?hnlich exponentilal- funktionen verhalten. fr diese sind wegen der kurzen wortl?nge von x aber oft tabellen m?glich, wodurch man beliebige kennlinien erzeugen kann. [1] crenshaw ?math toolkit for real-time programming cmp-books 2000 1 x y bild 4: kennlinien log & bitlog
d0 d7 a0 a3 rdy/bsy /cd1 d0 d1 d0 d1 /rd /wr /cs /rd /wr /cs reset 5vcf input-port output- port /en a0 a3 d0 d7 die vorzge gegenber einer floppy sind erheblich. die schnitt- stelle pa?t direkt an den bus einer 8 bit cpu. die bauform ist klein. es ist sowohl 3,3v als auch 5v versorgung m?glich. stromaufnahme ist mit ca. 50ma ertr?glich. die beiden varianten cf i und cf ii unterscheiden sich nur in der bauh?he. die dnnere cf i pa?t auch in cf ii stecker. 1994 mit 4 mbyte karten eingefhrt denen 1996 die heute bliche kleinste gr?sse 8 mbyte folgte. bliche speicher- dichten fr kleine varianten sind 8, compact flash an controller der ideale weg um einen einplatinencomputer mit so etwas wie einer floppy auszustatten. d.h. einen wechselbaren speicher mit dem man files von und zu pcs bertragen kann. 16, 32 mbyte. verfgbar, aber derzeit noch teuer, sind auch wesentlich gr??ere audfhrungen. da ursprng- lich fr laptops gedacht pa?t der 50pol steckverbinder ber einen passiven adapter in pcmcia-karten. neben dieser anschaltung ist alterna- tiv ?true ide m?glich. in diesem fall emuliert man genauso direkt eine harddisk. hier ist aber ?hot plugging, also stecken und entfernen der karte bei laufendem ger?t nicht vorgesehen. auf diese wnschenswerte eigen- schaft will man aber ungern verzich- ten. die dritte beschaltung ?common memory ist fr controller besonders geeignet. man h?ngt direkt memory mapped am bus der cpu. [1] www.compactflash.org ?cf+ and compactflash specification revision 2.0 [2] www.sandisk.com ?compact flash memory card product manual ?using sandisk flash ata components with an 8051 microcontroller [3] www.t13.org ?working draft x3t10/0948d ata-2 [4] www.renesas.com ?hitachi flash cards users manual ?q&a on hitachi cf and ata cards hardware wegen des ben?tigten rams ist ein einplatinencomputer sinnvol- ler als ein einchip-controller. die cf- karte liegt dann wie ein peripherie- baustein im speicher. wegen der zugriffszeit von 150nsec darf der bus nicht zu schnell sein. damit ?hot plugging m?glich ist, mu? er ber treiber die man tristate schalten kann abgetrennt sein ( bild 1 ). das verbessert auch den esd-schutz etwas. die treiber sind zudem n?tig, weil an der schnittstelle nicht ttl sondern cmos-pegel ge- fordert sind. die beschaltung deco- diert 16 register, ben?tigt werden typisch aber nur 8. also k?nnte man a3 auch auf gnd legen. neben der busanschaltung sind auch noch einige portpins erforderlich. mit /en schaltet die cpu die versorgung des speichers an. ber den pin reset kann er den speicher rcksetzen. die puls- breite mu? gr??er 10usec sein, es kann im betrieb 100msec dauern bis die karte wieder bereit ist. unmittel- bar nach powerup kann es auch 400msec dauern. typische zeiten schwanken von 5 - 250msec. zwar haben die karten nominell eine interne resetschaltung, aber normaler- weise wird man bei anlegen der versorgung reset=1 schalten und erst nach verz?gerung mit reset=0 freigeben. wenn man den pin nicht ansteuern will verbindet man ihn fest mit gnd. der rdy/bsy -pin zeigt an wann die karte den reset beendet hat und bereit ist. der pin mu? nicht zwingend auf port gelegt sein, man kann das bit auch in einem register abfragen. /cd1 ist im speicher mit gnd verbunden. damit prft die cpu ob eine karte steckt. sie wird dann die versorgung anschalten und damit auch die treiber freigeben. schaltung der hier verwendete mitsubishi-6502 fhrt jeden schreibzugriff als read-modify-write zyklus aus. das macht bei peripherie- bausteinen fast immer probleme. deshalb mu? man schreiben und lesen in unterschiedliche speicher- bereiche legen und die decodierung entsprechend ausfhren ( bild 2 ). die beiden ports sind hier 74hc-bausteine. beim register 74hc175 wird durch den reset /res der cpu die schnittstelle inaktiv geschaltet. da die stromaufnahme der karte typisch nur etwa 50ma betr?gt gengt ein wald&wiesen-transistor als schalter. 12 bild1: blockschaltbild
pcmcia cf 68 oberseite cf 34 1 35 oberseite cf 1 25 26 50 5vcf 100k r/w 74hc245 d7cf d0cf d7 d0 /en /en /cs2 /cs3 100k 5v d0 /cd1 100k 5vcf d1 rdy/bsy /cscf /wrcf /rdcf resetcf a3 a2 a1 a0 /cs0 r/w /r/w reset a3cf a2cf a1cf a0cf 74hc244 74hc244 phi2 /cs1 /en /res d1 d0 reset /en phi2 /cs3 /cs0 /cs1 /cs2 /cs3 r/w a8 a9 / ext1 a10 74hc138 74hc175 a15 a14 a13 a12 a11 /ext1 rot 1,8k 1k 4,7k /en 5vcf /r/w r/w tabelle 1: pins der cf-karte in memory mode sowie deren beschaltung 1 gnd gnd 2 d3 i/o d3cf 3 d4 i/o d4cf 4 d5 i/o d5cf 5 d6 i/o d6cf 6 d7 i/o d7cf 7 /ce1 i r /cscf 8 a10 i gnd 9 /oe i r /rdcf 10 a9 i gnd 11 a8 i gnd 12 a7 i gnd 13 vcc 5vcf 14 a6 i gnd 15 a5 i gnd 16 a4 i gnd 17 a3 i a3cf 18 a2 i a2cf 19 a1 i a1cf 20 a0 i a0cf 21 d0 i/o d0cf 22 d1 i/o d1cf 23 d2 i/o d2cf 24 wp o nc 25 /cd2 o nc 13 echte harddisks in cf-bau- form k?nnten jedoch bis 500ma ben?tigen und werden hier nicht bercksichtigt. das rote led zeigt dem benutzer an das die karte unter spannung steht und nicht gezogen werden darf. die pullups an 74hc244 und 74hc245 werden gebraucht, damit sie bei gezogener karte definierte bild 2: schaltung bild 3: nummerierung der pins blick auf rckseite der stecker 26 /cd1 o /cd1 27 d11 i/o nc 28 d12 i/o nc 29 d13 i/o nc 30 d14 i/o nc 31 d15 i/o nc 32 /ce2 i r 5vcf 33 /vs1 o nc 34 /iord i r nc 35 /iowr i r nc 36 /we i r /wrcf 37 rdy/bsy o rdy/bsy 38 vcc 5vcf 39 /csel i gnd 40 /vs2 o nc 41 reset i r resetcf 42 /wait o nc 43 /inpack o nc 44 /reg i r 5vcf 45 bvd2 i/o nc 46 bvd1 i/o nc 47 d8 i/o nc 48 d9 i/o nc 49 d10 i/o nc 50 gnd gnd bild 3: cf in pcmcia- sockel pegel am eingang haben. in der karte haben viele pins pullups und mssen deshalb am stecker nicht zwingend mit 5v verbunden werden. sie sind in tabelle 1 mit ?r gekennzeichnet. dort ist links der offizielle name sowie signaltyp und rechts das in der beschaltung angelegte signal ver- merkt. sockel die blichen cf-sockel mit ihren 0,64mm smd-kontakten sind fr breadboards ungnstig. von den pcmcia-sockeln gibt es eine varian- te die in laptops huckepack ber dem unteren sockel auf der leiterplatte montiert wird ( bild 3 ). dessen bedrahteten pins haben dann 2,54mm raster. es wird allerdings zus?tzlich ein handelsblicher pcmcia auf cf adapter ben?tigt. dessen modifizierte pinbelegung ist im anhang der cf- spec angegeben [1] ( tabelle 2 ).
tabelle 2: adapter pcmcia auf cf pcm cf cia 1 1 gnd 2 2 d3 3 3 d4 4 4 d5 5 5 d6 6 6 d7 7 7 /ce1 8 8 a10 9 9 /oe 10 - 11 10 a9 12 11 a8 13 - 14 - 15 36 /we 16 37 rdy/bsy 17 13 vcc 18 - 19 - 20 - 21 - 22 12 a7 23 14 a6 24 15 a5 25 16 a4 26 17 a3 27 18 a2 28 19 a1 29 20 a0 30 21 d0 31 22 d1 32 23 d2 33 24 wp 34 50 gnd 35 1 gnd 36 26 /cd1 37 27 d11 38 28 d12 39 29 d13 40 30 d14 41 31 d15 42 32 /ce2 43 33 /vs1 44 34 /iord 45 35 /iowr 46 - 47 - 48 - 49 - 50 - 51 38 vcc 52 - 53 - 54 - 55 - 56 39 /csel 57 40 /vs2 58 41 reset 59 42 /wait 60 43 /inpk 61 44 /reg 62 45 bvd2 63 46 bvd1 64 47 d8 65 48 d9 66 49 d10 67 25 /cd2 68 50 gnd 14 zugriff sp?testens in software hat man das modifizierte ata-interface vor sich. studium von ata-2 [3] als vergleich ist empfehlenswert. die ?common memory-betriebsart ist letztlich eine untermenge davon. es sind zwar mehr register vorhanden, praktisch gengen aber die ersten 8 register des ?task files ( tabelle 3 ). der eigentliche speicher ist fest in sektoren zu 512 byte einge- teilt. diese daten kommen sequentiell per protokoll durch das data - register. im echten ata-interface ist der datenbus 16 bit breit. bei dem hier vorliegenden 8 bit interface kommen die datenworte little-endian, was fr den 6502 gut pa?t, aber bei big-endian controllern zu berck- sichtigen ist. wenn man beim zugriff nicht nur einen, sondern mehrere sektoren bertragen will stellt man das vorher in sector-count ein: 00h 256 sektoren 01h 1 sektor 02h 2 sektoren ... hier wird immer nur 1 sektor bertra- gen, also einstellung 01h. in den registern x3 bis x6 wird die adresse des ersten sektors vorge- geben. es gibt dafr zwei varianten: chs ( ?cylinder, head, sector ) und lba ( ?linear block adressing ). hier wird die einfachere lba- adre?ierung verwendet. sie ist simpel ein 28 bit adre?wort das so ber die register verteilt ist: bit sector-number = 7 - 0 cylinder-lo = 15 - 8 cylinder-hi = 23 - 16 drive/head = 27 - 24 die obersten 4 bit von drive/head mssen fest auf 1110b eingestellt werden. einschalten der versorgungs- spannung erfolgt hier ( listing cf1.f74 ) mit up , abschalten mit down . mit dem befehl tf. kann man die register auslesen. das ergebnis sieht ca. so aus: 0 1 2 3 4 5 6 7 00 01 01 01 00 00 e0 50 wichtig ist der wert 50h im status- register, er zeigt an das die karte bereit fr befehle ist ( tabelle 4 ). das error- register kann man als erweiterung von status anse- hen. im normalen betrieb ist fr zugriff das busy -flag wichtig. sowie das flag drq das anzeigt wann ein datenbyte gelesen bzw. geschrieben werden kann. wenn zugriff m?glich ist, l?dt man in register x1 - x6 die passenden einstellung. soweit die lba-adresse nicht komplett erforderlich ist, mu? man nach reset zumindest die oberen 4 bit von drive/head initialisieren. dann schreibt man den befehls- token in das command -register wodurch der befehl ausgefhrt wird. von den 40 befehlen des standards sind normalerweise in der cf-karte nur 30 implementiert. in der ansteuerungssoftware hier auf 4 befehle reduziert. die bergabe der lba-adressen erfolgt dabei nicht ber stack sondern die 32 bit varia- ble lba . wenn man sich auf 32 mb karten beschr?nkt sind nur die unteren 16 bit n?tig und alles ober- halb statisch 000h. tabelle 3: register ?task-file adr read write x0 data x1 error features x2 sector-count x3 sector-number x4 cylinder-lo x5 cylinder-hi x6 drive/head x7 status command tabelle 4: status -register, error -register bit status 7 1 = busy 6 1 = rdy ready ( wait for rdy=1 after reset ) 5 1 = dwf write fault 4 1 = dsc ready 3 1 = drq data request 2 1 = corr correctable error was corrected 0 1 = err error in register error error 7 1 = bad block 6 1 = uncorrectable error 4 1 = id error 2 1 = abort , invalid command 0 1 = general error
die variable >cache zeigt auf den beginn das speichers im ram des controllers von dem der sektor gelesen, bzw. wohin der sektor geschrieben wird. ihre unteres byte ist immer 00h. daten lesen read-sector \ ( ) \ opcode 20 die lba-variablen entsprechend der adresse des ersten sektors werden in die register x3 bis x6 der karte kopiert. in sector-count speichert man die zahl der sektoren die man lesen will. hier soll immer nur ein sektor bertragen werden, also 01h. dann schreibt man den befehlscode 20h und wartet darauf, das in status das bsy -flag gel?scht und das drq - flag gesetzt ist. w?hrend des lesens der folgenden 512 byte aus data mssen die flags in status nicht geprft werden. daten schreiben write-sectors \ ( ) \ opcode 30 write-sectors funktioniert wie read-sectors mit ge?nderter richtung der datenbewegung. das schreiben der bytes einzelner sekto- ren erfolgt ungebremst, weil diese im ram der karte gepuffert werden. da das schreiben von flash aber dauert, kann dann eine pause von 700usec ( ?class 2 befehl ) auftreten bis das drq -flag wieder gesetzt wird. hier wird explizit gewartet bis die karte wieder bereit ist. sonst k?nnt man z.b. mit down irrtmlich die versor- gung abschalten w?hrend die karte noch am speichern ist. einstellungen lesen identify-drive \ ( ) \ opcode ec ?hnlich wie mit dem read-befehl werden 512d byte einstellungen und herstellerinformationen aus der karte ausgelesen ( tabelle 5 ). speziell fr formatierung kann man so die speichergr?sse bestimmen. identify-drive. \ ( ) ist der zugeh?rige druckbefehl ( tabelle 6 ) am beispiel einer 8 mb karte. standby sleep \ ( ) opcode 99 reduziert den stromverbrauch auf <1ma. reaktivierung erfolgt durch beliebigen befehl. da echte harddisks stromfresser sind hatte ata diverse befehle fr standby definiert. weil 15 tabelle 5: identify drive wrd default bytes adr data 0 848ah 2 general configuration bits 1 xxxx 2 default number of cylinders 2 0000 2 reserved 3 xxxx 2 default number of heads 4 0000 2 unformatted bytes per track (obsolete) 5 0240 2 unformated bytes per sector (obsolete) 6 xxxx 2 default number of sectors per track 7 xxxx 4 msw number of sectors per card 8 lsw 9 0000 2 reserved 10 aaaa 20d serial number in ascii right justified 20 0002 2 buffer type = dual ported (obsolete) 21 0002 2 buffer size in 512 byte increments: 1k (obsolete) 22 0004 2 # of ecc bytes passed on r/w long 23 aaaa 8 firmware revision ( big endian ) 27 aaaa 40d model number ( big endian ) 47 0001 2 maximum of 1 sector on r/w multiple 48 0000 2 double word not supported (obsolete) 49 0200 2 dma not supported , lba not supported 50 0000 2 reserved 51 0200 2 pio data transfer cycle timing mode 52 0000 2 dma data transfer cycle tim. not supported (obsolete) 53 0003 2 field validity 54 0003 2 current number of cylinders 55 xxxx 2 current number of heads 56 xxxx 2 current sectors per track 57 xxxx 4 lsw current capacity in sctors 58 msw 59 010xh 2 multiple sector setting is valid 60 xxxx 4 total number of sectors addressable 61 in lbamode 62 xxxx 4 reserved 63 64 0003 2 advanced pio modes supported 65 0000 4 reserved 66 67 0078 2 minimum pio transfer without flow control 68 0078 2 mimimum pio transfer with iordy flow control 69 0000 130d reserved 128 0000 64d reserved vendor unique bytes 160 0000 192d reserved
tabelle 6: test identify-drive | up \ switch power on | identify-drive \ read data | identntify-drive. \ print data general configuration bits 848a default number of cylinders 00f6 default number of heads 0002 number of unformatted bytes per track 0000 number of unformated bytes per sector 0200 default number of sectors per track 0020 number of sectors per card 0000 3d80 serial number x0102 20030724025939 buffer type = dual ported = 0002 0002 buffer size in 512 byte increments 0002 # of ecc bytes passed on r/w long 0004 firmware revision rev 2.00 model number hitachi xxm2.2.0 maximum of 1 sector on r/w multiple 0001 double word not supported = 0000 0000 dma not supported , lba not supported = 0200 0200 pio data transfer cycle timing mode = 0200 0100 dma data transfer cycle tim. not supported =0 0000 field validity 0001 current number of cylinders 00f6 current number of heads 0002 current sectors per track 0020 current capacity in sectors 0000 3d80 multiple sector setting is valid = 010x 0100 total number of sectors addressable in lbamode 0000 3d80 advanced pio modes supported = 0003 0000 minimum pio transfer without flow control= 0078 0000 mimimum pio transfer with iordy flow cntrl 0078 0000 | down \ power down 16 sich cf-karten automatisch recht schnell runterschalten sind solche befehle hier fast nicht n?tig. abschal- ten der versorgung ist wegen der langsamen einschaltzeit vieler karten aber auch unattraktiv. einschr?nkungen die schaltung funktioniert nicht fr alle karten. ein exemplar casio 8mb mit hitachi-innereien war nicht ansprechbar. funktioniert aber an kartenleser am pc. erkl?rung findet sich eventuell in angaben im hitachi-handbuch zur behandlung des /oe-pins beim powerup. der aufwand auch pathologische ?ltere karten zu bercksichtigen scheint aber nicht gerechtfertigt. adler-32 in rfc-1950 gibt es von 16 bit fletcher eine aufwendige variante die bei etwas geringerer fehlersicherheit immer noch effizienter als crc32 in software sein soll. bei fletcher wird der modulo- berlauf der beiden akkumulatoren ignoriert. man kann den inhalt der akkumulatoren auch als rest einer division durch 65536 interpretieren. bei adler ist der rest einer division durch die primzahl 65521 vorgese- hen, in bild 3 durch den befehl ?mod der nur den rest als ergebnis hat dargestellt. durch passende auslegung des programms ist es wohl m?glich die division nur nach 5552 bytes ausfhren zu mssen. trotzdem scheint das verfahren fr kleine controller nicht attraktiv. [1] fletcher ?an arithmetic check- sum for serial transmission ieee trans. on communications jan. 1982 [2] sklower ?improving the efficiency of the osi checksum calculation acm computer communication review okt. 1989 ( fortsetzung von s.17 ?fletcher prfsumme ) ( fortsetzung von s.20 ?lineare interpolation ) diese umrechnung kann man durch eine passende routine automa- tisch vornehmen: maximalen fehler an der sttzstelle und den 3 davor- liegenden interpolierten punkten berechnen und abspeichern. dann den wert an der sttzstelle dekre- mentieren bzw inkrementieren ( je nach vorzeichen der abweichung an den sttzstellen). darauf nochmal den maximalen fehler an allen 4 punkten berechnen. ist er gr??er geworden als der gespeicherte wert den letzten schritt rckg?ngig ma- chen und optimierung beenden. als alternative abbruchbedingung wird geprft ob das vorzeichen des fehlers wechselt. d.h. ob man den wert an der sttzstelle so weit verschoben hat, da? er selbst nun den maximalen fehler enth?lt. was natrlich nicht sein soll ( listing mlint.f74 ). man sollte sich anhand der 4kbyte tabelle als referenz den fehler der berechneten punkten ausdrucken ( tabelle 1 ). bei der funktion x^2,5 ist der relative fehler anfangs extrem hoch. am ende der tabelle wird er geringer. in der beabsichtigten anwendung waren werte unterhalb 50h und oberhalb 200h von geringer bedeutung. soda? keine weiteren optimierungen n?tig waren.
lb = 0 hb = 0 i = 0 lb = lb "+" data(i) hb = hb "+" lb i = i + 1 y n more data ? +127 7f 7f 2er 1er komplement +1 01 01 +0 00 00 -0 ff -1 ff -2 fe fe -127 80 -128 80 fletcher prfsumme in software ohne tabellen schneller berechenbar und fast so wirk- sam wie crc. erste breitere anwendung er- folgte in osi-protokollen. da pakete aus bytes bestehen, wurde hier als wortbreite der daten 8 bit verwendet. wie auch in [1] als g?ngigste variante angenommen. bild 1 zeigt schema- tisch den ablauf. es gibt zwei akku- mulatoren lb und hb deren l?nge dem datenwort, also einem byte entspricht. nach ende der berech- nung werden die akkumulatoren zur prfsumme, hier also mit 16 bit l?nge zusammengesetzt. typisch wird diese little-endian dem paket angeh?ngt. es sind nur additionen erfor- derlich, aber berechnung in 1er- komplement ist besser als in 2er- komplement und deshalb blich [1]. in bild 1 ist diese etwas andere addition durch ?+ gekennzeichnet. 1er-komplement eine recht ungebr?uchliche variante der zahlendarstellung ( bild 2 ), die arithmetik blicher cpus verarbeitet 2er-komplement direkt. fr 1er-komplement ist hier die nachtr?gliche addition des carrybits n?tig. beispiel: fe \ -1 + 04 \ + +4 ----- 0102 \ 02 ; carry 02 + 01 \ add carry ----- 03 \ = +3 bei 8 bit cpus damit nur ein zus?tzli- cher opcode f?llig: fe #. lda, \ -1 04 #. add, \ +4 00 #. adc, \ +carry da man in forth mit 16 bit wort- breite rechnet, kann man sich kompli- ziertere programme ausdenken, bei denen das carrybit von bis zu 255d bytes akkumuliert wird, bevor man es in einem korrekturschritt zum unte- ren byte summiert. auf einem controller drfte jedoch der simple algorithmus in assembler eine deutlich effizientere l?ung sein. null wenn man bei crc mit start- wert null alle bytes eines pakets und die prfsumme addiert ist das korrek- te ergebnis null. es hat sich einge- brgert dieses verhalten auch anderen prfsummen aufzuzwingen. dazu mu? man die prfsumme passend doktern, bevor man sie dem paket anh?ngt. als grund dafr wird angegeben, da? mehraufwand im sender sinnvoll ist, wenn er zu geringerem aufwand im empf?nger fhrt. denn ein paket wird nur einmal erstellt, aber beim weg durch ein datennetz wird die prfsumme oft berprft. wenn alle bytes des pakets null sind, ist auch die prfsumme null. auch dagegen gibt es einw?nde, soda? fr fletcher ein patch blich ist 00 auf ff zu ?ndern. beide modifi- kationsschritte sind in bild 3 darge- stellt. nur im sender ben?tigt, emp- f?nger ?addiert beide bytes konven- tionell um das ergebnis null zu erhalten. im listing flet1.f74 in 6502- assembler fr 8 bit fletcher als prfsumme fr speicher aufgefhrt. fletcher-16 fr internetanwendungen z.b. rfc-1146 wird alternativ zu 8 bit die 16 bit fletcher mit 32 bit prfsumme favorisiert. weil auf gro?en cpus effizienter [2]. die akkumulatoren sind nun 16 bit breit, am rechen- schema ?ndert sich nichts. da aber nun 16 bit worte eingelesen werden, mu? man in paketen ungerader l?nge das letzte byte um 00h erg?nzen. big/ little-endian-probleme sind natrlich auch noch m?glich. anders als bei iso wird die prfsumme nicht so modifiziert, da? die summe null ergibt. ( fortsetzung auf s. 16 ) bild 1: berechnung der prfsumme bild 4: adler-variante 17 bild 2: 1er/2er komplement 8 bit bild 3: modifikation des endwerts y n lb = ffh - ( lb "+" hb ) hb = hb hb = 00 ? y n lb = 00 ? hb = ffh lb = ffh lb = ( lb "+" data(i) ) mod fff1h hb = ( lb "+" hb ) mod fff1h
rfid-id 64 bit 10 bit hash-key 3ffh 000 eeprom 1024 x 64 bit hash-function 18 die preiswertesten 125khz transponder ( rfid ) haben eine feste nummer die vom hersteller z.b. per laser eingeschrieben wird. damit dieser trotz kontinuierlicher ferti- gung eine ?einzigartige serien- nummer garantieren kann, ist diese ziemlich lang, typisch 64 bit. da darin auch prfsummen enthalten sind, ist die effektive l?nge krzer. um portierung zwischen verschiede- nen anbietern zu vereinfachen ist es fr ein leseger?t trotzdem gnstiger mit der vollen l?nge von 64 bit zu arbeiten. bei anwendung in gr??eren geb?uden und hotels kann es erfor- derlich sein, da? das leseger?t hunderte von schlssel erkennen soll. wenn diese in einem externen seriel- len eeprom gespeichert sind, ist der zugriff langsam ( bild 1 ). um die hashing fr rfids rfids sind ber funk abfragbare seriennummer-ics. hashing ist ein verfahren fr effizientes suchen in listen. bild 1: leseger?t bild 2: adre?generierung bild 4: id-generatoren lfsr startwert 1... lfsr startwert a... lfsr startwert f ... z?hler startwert 0... bild 3: suche reaktionszeit des leseger?ts kurz zu halten mu? die suche optimiert werden. hashing das suchen in ungeordneten langen listen ist ein altes problem der datenverarbeitung und eine bekannte l?sung hei?t hashing. durch eine geeignete hash-funktion wird aus dem 64 bit datensatz des transpon- ders ein 10 bit wert berechnet, der als zeiger in die liste mit den 1024 x 64 bit worten dient ( bild 2 ). dort sucht man nun linear aufw?rts weiter. wenn oberhalb 3ff ein moduloberlauf eintritt, geht die suche ab adresse 000 weiter ( bild 3 ). der endpunkt ist der ursprngliche einsprungpunkt auf den der hash-key zeigt. normaler- weise mu? man aber nur ein kurzes stck linear suchen. beim einpro- grammieren eines transponders sucht man die n?chste leere speicherzelle, also alle 64 bits gesetzt. dort pro- grammiert man die rfid-id ein. beim suchen vergleicht man die rfid-id des transponders mit dem inhalt der speicherzelle auf identit?t. bzw. ob die speicherzelle leer ist. in letzterem fall ist die id nicht im eeprom. das verfahren reduziert die suche in einer langen liste auf die suche in vielen kurzen listen. diese entstehen zwangsl?ufig, da hash- kollisionen, also mehrere ids zeigen auf eine teilliste, nicht vermeidbar sind. weiter entwickelte hash- verfahren fhren statt linearer suche noch einen 2. hash-schritt durch, aber das ist hier zu kompliziert. besonders weil man aus dem seriellen eeprom nach der startadresse die folgenden bytes kontinuierlich lesen kann, w?hrend man fr sprnge nochmal kopf und adresse schreiben mu?. effizienz die wirksamkeit des verfah- rens h?ngt von der statistik der eingangsdaten und der anpassung der hash-funktion an diese ab. ferner davon wie voll der speicher ist. eeprom 24c64 controller 68HC908 rfid em4102 eeprom p=1 p=0,5 bit 63 bit 0
rfid-id hash-key 19 bild 3: hash-funktion aus einzelbits ein simpler verteilungstest ist fr alle 64 bits die wahrscheinlich- keit zu ermitteln fr die das bit den wert 1 hat. dazu l?sst man den generator z.b. 1024 samples erzeu- gen und z?hlt dabei in 64 z?hlern mit ob das jeweilige bit 1 war. fr einen echten, guten zufallszahlengenerator w?re der wert berall 50%. beim 64 bit lfsr a la stahnke ist die vertei- lung etwas vom startwert abh?ngig ( bild 4 ). das liegt auch daran, da? die stichprobe zu klein ist: nur 1024 von (2^64)-1 worten. beim bin?r- z?hler ist die schlagseite offensicht- lich. nur die untersten bits ?ndern sich. hash-funktionen simpelste variante ist einfach nur bestimmte bits zu kopieren ( bild 3 ). geeignet sind bits die m?glichst mit 50% wahrscheinlichkeit den wert 1 haben. beim bin?rz?hler sind das die untersten bits. in der hash- adresse haben die oberen bits die gr??te wirkung, also wird man sie dorthin legen. entsprechnd wrde man h?herwertige bits der id gerin- ger bewerten. das verfahren funktio- niert also nur sicher, wenn die stati- stik des eingangssignals bekannt und verl??lich ist. in der praxis ist das selten der fall, robustere verfahren sind n?tig. z.b. solche zur prfsummen- berechnung. in [2] schneiden crcs , flechter und simples xor ber alle bytes recht gut ab. bezglich fehler- sicherung ist die stark abfallende qualit?t dieser verfahren bekannt. fr hashing sind die qualit?tsunter- schiede aber nicht so deutlich. ein problem bei der implementierung ist, da? fr die hash-adresse der krumme tabelle 1: ergebnisse simulation a = lfsr startwert: 1000 0000 0000 0000 0000 0000 0000 0000 b = lfsr ffff ffff ffff ffff ffff ffff ffff ffff c = lfsr aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa d = z?hler 0000 0000 0000 0000 0000 0000 0000 0000 crc 0 1 2 3 4 5 6 7 8 9 a b c d sum a 0243 0088 009d 004d 002a 0018 0008 0001 0000 0000 0000 0000 0000 0000 033f b 0245 0089 0091 005b 0026 0016 0008 0002 0000 0000 0000 0000 0000 0000 034f c 0246 0086 008f 0060 0027 0017 0004 0003 0000 0000 0000 0000 0000 0000 0343 d 0001 03fe 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 fletcher a 0183 0162 00c8 0042 000d 0004 0000 0000 0000 0000 0000 0000 0000 0000 01a0 b 0172 0189 00b3 003d 0011 0002 0002 0000 0000 0000 0000 0000 0000 0000 01a1 c 0171 0178 00cf 003a 000a 0004 0000 0000 0000 0000 0000 0000 0000 0000 018b d 00c8 027b 00b2 000b 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 00c8 xor a 0286 0097 0067 002b 0022 0005 000f 0009 0006 0003 0001 0002 0000 0000 0b7d b 0312 0026 0033 002a 0018 0019 0011 000d 0007 0008 0002 0001 0004 0002 2e1f c 0317 0035 0030 001c 0018 0013 000c 000b 000b 0008 0004 0005 0003 0001 2c40 d 0300 0000 0000 0001 00fe 0001 0000 0000 0000 0000 0000 0000 0000 0000 0402 bild 5: verknpfung von hash- funktionen durch xor wegen des statistischen einflusses kann man die reaktionszeit des systems nur per monte carlo simula- tion verifizieren. und h?ngt stark davon ab wie gut man die rfid-ids nachbilden kann. id-statistik fr die produktion von ids gibt es zwei varianten: simple bin?r- z?hler oder pseudozufallszahlen. wenn letztere z.b. durch lfsr mit m-sequenz erzeugt werden, ergeben sich auch einzigartige ids. die hersteller von transpondern machen keine angaben wie sie ihre ids erzeugen. es scheint sich aber um zufallszahlen zu handeln. von microchip ist fr pics bekannt, da? sie lfsr mit wenig taps verwenden [1]. insofern liegt man mit dem simplen 64 bit polynom von stahnke [1] fr simulation wohl durchaus richtig. rfid-id hash-function hash-function hash-key 8 bit 8 bit xor
werte 10 bit ben?tigt wird. einfache l?sung ist aus jeweils 32 bit zwei 8 bit teilworte zu bilden und diese durch xor zu verknpfen ( bild 5 ). test man l??t den generator wieder 1024 muster erzeugen die dann ber die hash-funktion auf 10 bit adres- sen komprimiert werden. anhand dieser inkrementiert man jeweils einen von 1024 16 bit z?hlern die die speicherzellen des eeproms darstel- len. im idealfall enth?lt jeder z?hler nach ende des tests den wert 1. jede rfid-id w?re dann einer anderen adresse zugeordnet worden. prak- tisch kommt es aber zu kollisionen, also enthalten manche z?hler werte gr?sser 1. dementsprechend werden einige adressen behauptnicht angesprochen und enthalten den wert 0. tabelle 1 zeigt die ergebnisse fr 8 bit crc, fletcher und xor. mit testdaten erzeugt vom bin?rz?hler und lfsr, letzterer mit 3 verschiede- nen startwerten ( vgl auch bild 4 ). die spalte ?1 enth?lt die guten f?lle, rechts davon sind die kollisions- fehler. um den vergleich zu vereinfa- chen ist am ende noch eine gewichte- te fehlersumme aufgefhrt, die mehrfachkollisionen versch?rft bewertet. dreifachkollisionen mal 2, vierfachkollisionen mal 4, fnffach mal 8 usw. die crc erreicht zwar hier nahezu ideale werte fr den z?hler. aber das ergebnis von fletcher ist ausgeglichener. xor ist sehr schlecht, man beachte die vielfach- kollisionen weit rechts in der tabelle. [1] ?pn-sequenzen embedded (5) s. 6 [2] jain ?a comparison of hashing schemes for adress lookup in computer networks ieee trans. on com 1992/10 s. 1570 - 1573 y 4 0 y tabelle fehler tabelle optimierte lineare interpolation in tabellen ein simples, wohlbekanntes verfahren wird genauer wenn man die tabellen optimiert. bild 1: interpolation, direkt & optimiert. hier anhand der berechnung y = x^2,5 dargestellt. wobei fr x werte von 0 ... 400h berechnet werden sollen. eine direkte 32 bit tabelle wrde 4kbyte speicher ben?tigen. die hier gew?hlte alternative ist, eine ver- krzte tabelle zu verwenden die nur jede 4. sttzstelle enth?lt und damit nur 1kbyte belegt. die berechnung der 3 anderen punkte durch lineare interpolation ( bild 1 ) erfordert nur additionen und shiftbefehle und ist damit auch auf controllern sehr leicht durchfhrbar. dabei ist eine sprung- zieltabelle die von den untersten tabelle 1: fehler unoptimierte tabelle: ref fehler = x y approx - ref 0000 0000 0000 0000 <- 0001 0000 0001 0007 0002 0000 0006 000a 0003 0000 0010 0008 0004 0000 0020 0000 <- 0005 0000 0038 000d 0006 0000 0058 0012 0007 0000 0082 000d 0008 0000 00b5 0000 <- ... 03f8 01f6 0efb 0000 <- 03f9 01f7 4b79 00b3 03fa 01f8 886e 00ef 03fb 01f9 c5db 00b3 03fc 01fb 03bf 0000 <- 03fd 01fc 421c 00b3 03fe 01fd 80f0 00ef 03ff 01fe c03c 00b3 0400 0200 0000 0000 <- optimierte tabelle: ref fehler = x y approx - ref 0000 0000 0000 + 0000 <- 0001 0000 0001 + 0005 0002 0000 0006 + 0007 0003 0000 0010 + 0003 0004 0000 0020 - 0006 <- 0005 0000 0038 + 0006 0006 0000 0058 + 000a 0007 0000 0082 + 0004 0008 0000 00b5 - 000a <- 03f8 01f6 0efb - 0077 <- 03f9 01f7 4b79 + 003c 03fa 01f8 886e + 0078 03fb 01f9 c5db + 003c 03fc 01fb 03bf - 0077 <- 03fd 01fc 421c + 003c 03fe 01fd 80f0 + 0078 03ff 01fe c03c + 003c 0400 0200 0000 - 0078 <- beiden bits von x gesteuert wird eine geeignete art der implementierung ( listing lint.f74 ) optimierung wie in bild 1 auch dargestellt ist, sollte man nicht einfach die ausgednnten werte der 4kbyte tabelle verwenden. man h?tte dann zwar an den sttzstellen minimalen fehler, aber an den interpolierten punkten um so mehr abweichung. wnschenswerter ist eine gleich- m??ig kleine abweichnung an allen punkten. wie in bild 1 dargestellt, dadurch erreichbar, da? man den wert an den sttzstellen etwas verschiebt. 20 ( fortsetzung s.16 )

▲Up To Search▲

Price & Availability of 68HC908

	To Download 68HC908 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .